昨天介紹了數位轉型後，在軟體轉型的第一個案例，是可以透過外部廠商的制式化軟體，讓原本系統可以轉移的案例。但有許多內部使用的系統，往往因為高度機密性，或是資料涉及許多不同內部單位的資料串接，無法直接找到可匹配的外包軟體套用，而必須內製開發，例如今天要介紹的 CRM 系統。

除了內部不同單位系統串接外，資料的正確性、系統控管的資安程度、不同內部系統資料拋轉的難題，都會是 CRM 系統要考量的項目。來看看這個系統的狀況與說明吧！

Situation

• 公司內部近六成人員使用的老舊系統，約有十年的技術代溝
• 系統資料須與其他部門串接，連動的資料拋轉頻繁
• 技術停留在前、後端程式未拆分，造成維護上的困難
• 從早期都是自由填寫，慢慢拆解才有模組化內容，但已經產生許多髒資料，導致報表容易錯誤
• 過去的高度客製開發與維運，牽一髮動全身的操作，往往造成系統崩潰需緊急救援的維護成本
• 由於架構老舊，新需求疊加不易
• 沒有手機版，讓操作人員需要紙本書記後，再用電腦補述
• 部分流程仍停留在紙本、各項紀錄往往需要信件、紙本保存多重管道追蹤，容易造成資訊不對等的情況

Task

• 藉由產品經理角色導入，協助內部人員逐步建立產品觀念，作為中間溝通橋樑，減低需求、開發團隊的認知落差
• 系統資料文件化，將需求討論透過文件溝通，逐步成形為規格書
• 整合開發人力，每周與需求方的例會，釐清各項底線與架構建議，開發前透過架構師及前、後端工程師密切討論，於方向一致後，每周拆分任務進行開發，提升團隊默契、產能更聚焦

Action

• 需求端思維轉型
  • 系統流程重新切分檢視：需求團隊的產品思維提升，並從日常營運將各項需求系統化
  • 系統權限重新定義：將所有使用人，清楚切分使用權限、資料權限，更明確劃分不同單位人員的職掌與分工
• 產品設計引導
  • 流程圖重整：從正向流程思考轉向泳道圖，提供跨組織、跨人員形式的流程思考
  • 加入使用者體驗設計：除了基本需求之外，加入使用者體驗設計界面的操作，並考量不同角色使用的流暢度，讓系統使用體驗加分
  • 盤點各種使用者情境：經過不同情境的細節檢視、歸納整理後，綜合出各種結果才匯集出最終的功能設計
  • 導入功能性、使用體驗測試：透過不同維度的測試，降低交付產品的落差
• 技術端支援
  • 資料正規化、正確化：將常用的固定資料正規畫，減少資料錯誤，大大降低維運的人為失誤
  • 從 pilot 系統開始：初步建立雙方驗收的系統驗收，增強彼此信任與合作默契
  • 開發流程循序漸進：逐步提供開發成果，並進行使用者功能、需求驗收、增加使用者體驗測試，才交付給需求方

Result

• 從需求端控制一切、老舊系統造成的產品效率低、維運成本高的困境，轉為聚焦核心業務的產品開發
• 建立需求端對軟體使用的認知，與新一波從需求端開始的流程制度的改革，逐步讓數位轉型，從 IT 部門擴展到需求單位的轉型
• 改善需頻繁修改、bug 回報、等待修正週期長、中斷 IT 事務的狀況，讓系統穩定度提升，增加需求方信賴度
• 透過產品思維再造，到系統使用流程再造，讓需求團隊意識到如何將需求說明準備好，跟 IT 進行更順暢的需求溝通
• 初期 pilot 開發成本費時費力，但透過各區同仁參與測試，讓後續系統推行更順暢
• 產品思維觀念建立後，大大提升需求端對功能的提案完整度，讓團隊能往同方向前進，達到雙贏的目的

後記

終於來到最後一天了，過去看了這麼多鐵人 30 天競賽的文章，只有當自己投入其中之後才知道有多麼困難
感謝過去能身處在專業的團隊，在面對如此緊湊的數位轉型專案推動的節奏中，能有自己貢獻的機會，以至於職涯有機會可以從一般工程師跟著團隊轉型為 SRE，也因為有優秀的 IT 管理層，以至於能夠看見僅僅靠自己無法達到的風景。

過去 30 天的文章，其實也僅僅是整個團隊在組織內推動數轉的一部分，還有很多內容可以談，包含技術實作面等等。然而最重要的要能夠從立案、資源盤點、定錨、轉型實作、IT 團隊建立、產品再造相信走過或走在這條路上的人知道有多麽不容易，以至於才有這一系列鐵人賽的文章出現。特別感謝過去團隊提供相關的專業資料與內容，才有辦法完成這一系列的挑戰，為團隊留下紀錄、為過去彼此一起努力過的戰場留下紀錄。

最後要謝謝老婆，當初轉換職場也是因為她的鼓勵才會轉換職場跑道，而在過去將近4年的團隊推動轉型的過程中老婆也看在眼裡，而這 30 天要能夠發文章其實有她的支持很重要，每一天有很多生活的大小事要做，她都盡力幫忙，或是能夠把過去點點滴滴的回憶拉起來也都有她的一份力。總之，要完成這 30 天挑戰要謝的人太多了，就謝天吧~

期待未來再相見~